\chapter{$\pi$SOD-M Validation}
\label{chapter:validation}

\epigraph{``\textit{Let us change our traditional attitude to the construction
of programs: Instead of imagining that our main task is to instruct a computer
what to do, let us concentrate rather on explaining to human beings what we want
a computer to do.}''}{Donald E. Knuth}


This chapter validates the $\pi$SOD-M methodology proposed in this thesis. The
chapter presents two case studies and reviews the thesis' concepts and proposed
methodology models and development process. The validation split the thesis into
parts, each one can be validated individually. This parts are: (i) the modelling
of each $pi$SOD-M model, (ii) its transformations and (iii) the consistence
results.

This chapter is structured as follows: in Section \ref{sec:strategy} we
present the validation strategy, in Section \ref{sec:crimes_inpractice} we
present the case study about the \textit{Crimes' Map} application, in Section
\ref{sec:toPublishMusic_inpractice} we describe and model the \textit{To Listen
Music} case study. Finally, in Section \ref{sec:conclusion_validation} we
present the chapter conclusion and the results collected in the methodology
validation. 

%The thesis' validation of the  follows from the sub-validations.   
 
\section{Validation Strategy}
\label{sec:strategy}

The \textit{IEEE Standard Computer Dictionary} \cite{ieeeDict} defines
validation as \textit{the process of evaluating a system or component during or
at the end of the development process to determine whether it satisfies specified
requirements}. If we apply this definition for a methodology approach
we have: \textit{Validation is the process of evaluating a method
during or at the end of the development process to determine whether it
satisfies specified team need and the easy system development}. The same
document define \textit{Process} in the context of \textit{Methodology Process}
as: \textit{a sequence of steps performed for a given purpose; for example, the
software development process}. Therefore, this Chapter aims to validate the
methodology proposed in this thesis in order to verify the steps proposed
to a better development of reliable services composition applications. The steps
during the thesis were analyzed by application of laboratory case studies
with an iterative and incremental approach. Thus, while the $\pi$SOD-M concepts
have been defined, the concepts application have been made in each case studies
to verify its validity.

The validation process has been performed in a continuous and
progressive approach along the methodology definition. From strategy for
validation, the process was carried out with the development resolution step as
part of an iterative process and feedback cyclic, allowing solve problems of
concepts and its application while the methodology was being defined. Thus, in
each step of methodology the validation was applied iteratively
on two different case studies.

The process defined in the research method validation was therefore not
a linear process, but iterative and incremental, thus providing the opportunity
to go strengthen the results and learning from each research step.  

Following, each developed case study is described, indicating both the needs
identified, and new contributions emerged from them, which are also shown
graphically, using the methodology models. The case studies resolution were
performed using the proposed approach.  


\section{$\pi$SOD-M in Practice}
\label{sec:execution}

This section presents, in detail, the design and implementation of two case
studies conducted to validate the method proposed in this
thesis. Both case studies were developed using the models proposed by
$\pi$SOD-M. 

% Following all models will be developed for this case and then
% describe the main aspects of the implementation of each of them.

\subsection{Crimes' Map}
\label{sec:crimes_inpractice}


The \textit{Crimes' Map} addresses the design and implementation of
statistical data on criminal activities. The system have to work in conjunction
with third-party services, during a search held by an user. The system aims to
provide a public utility service quality in order to provide to the citizens the
real crime situation in a particular location or region.

Making use of third party services, the application must provide a statistics
crime portal. The result depends on user queries. The user will also feature
the presentation in a map. The system also aims to interact with
micro-blogging, investigating related messages disseminated by a specific crime information.   

The criminal activities data presentation must be given by the \textit{Police
service}. The presentation of a locality map crime is made by
the \textit{Google Maps service} and presentation of messages on the
micro-blogging will be made by the \textit{Twitter service}. The system also has
to its inner workings a \textit{Post service}, for search the specific
location before publish the specific coordination address on Google Maps.   


The scenario to query data and crime statistics have the following actors:
\textit{(i) User, (ii) Map service, (iii) Post service, (iv) Micro-blogging
service} and \textit{(v) Police service}, to query the criminal activities.

Considering the application functions, the crimes can be searched by types,
\textit{e.g.} \textit{theft, murder, kidnapping} and etc. The search can also be
made by city district or region, for example, \textit{center, west, south,
north} or \textit{east}, and the type of research can be conducted for a
specific period, for example, crimes of the previous day, the last weeks or
months. Finally, all types of research can be combined, \textit{e.g.}, \textit{the
number of kidnapping of a specific district in the last month}.

Whenever a new crime is published by the police, the system should post a
 message on Twitter stating the new crime, with a specific hashtag,
 \textit{e.g.} \textit{\#crime043\_kidnapping\_center\_05-08-2012}. The hashtag
 structure means the crime number, type, local and the day it happens. From
 this, people can comment about the crime and theses comment will appear in the
 application. All users must have a account to use the application.

 The application requirements are: \textit{Choose search type of crime; see
 crime information; Receive information on the chosen query; See map; List crimes;}
 and \textit{Comment about a crime;}  

\subsubsection{$\pi$-UseCase Model}
\label{sec:usecase_crimesMap}


The modeling of the system starts with the $\pi$-UseCase model. From this
model, it will be able to identify, first, the scope and limits of the SIW
to be developed. This involves determining the services identified in the list
of requirements, which final consumers identified in the list of business
services, and which of the will be end consumers or service users. Thus, it is
possible to identify the modeling elements that are part of the use case model.
 
 Figure \ref{fig:usecaseCrimeMap_total} presents the $\pi$-UseCase
model for the problem described. The model considers the different
type of constraints, \textit{business, value} or \textit{exceptional
behaviours}. The main services to be used by the crimes' application are: \textit{Map
Service, Police Service, Postal Service} and \textit{Microb-logging Service}.
Thus, the application accesses data from a third party to provide the user an
easy way to visualize new information.

The user interact with the application that will perform the services
for details about the crimes. The services are modeled as actors, because
are external applications. Each service has a set of functions that can be
performed. These services have been identified from the system requirements.
The $\pi$-UseCase model describes well both, the external services, and the
functionality of the application.

\begin{figure}[ht!]   
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/crimes_useCase}
\caption{Crimes' Map $\pi$-UseCase.}
\label{fig:usecaseCrimeMap_total}
\end{figure}  

The user can search the crimes and view its occurrences in a map. The search
can be performed in different ways. The search may be performed by \textit{type of
crime, region} or \textit{period}. The User can also perform a search by
combining these properties. If the application's user does not choose any
option, the search will be spare occurrences of the last week, not to exceeding
the number of 30 occurrences. If the location maps service is unavailable or
there is no response after 5 seconds, only the crimes information will be
presented, without maps view.


Figures \ref{fig:usecaseCrimeMap1} and \ref{fig:usecaseCrimeMap2} detail the
use cases and constraints presented in Figure
\ref{fig:usecaseCrimeMap_total}. Figure \ref{fig:usecaseCrimeMap_total} also
presents the $\pi$-UseCase model tree representation generated by the $\pi$SOD-M
environment model . Figures \ref{fig:usecaseCrimeMap1} and
\ref{fig:usecaseCrimeMap2} detail the model properties.

\begin{figure}[ht!]   
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/crimes_useCase1}
\caption{\textit{search crime} $\pi$-UseCase Detail.}
\label{fig:usecaseCrimeMap1}
\end{figure}  

The \textit{search crimes} use case (Figure \ref{fig:usecaseCrimeMap1}) should
request the police service to verify the crimes according to the parameters
described by the User. The restriction  of this use case depends on the
parameters selected by the User. If he choose one or several types of
specific crime's type, it will be presented those which have more than five
occurrences. For \textit{search by address}, the address data must
comply with the restrictions of the police service,  the research can be
done by street, neighborhood, city or district. For \textit{search by period},
it will be presented only occurrences of the last six months.        
 
\begin{figure}[ht!]   
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/crimes_useCase2}
\caption{\textit{see crime information} $\pi$-UseCase Detail.}
\label{fig:usecaseCrimeMap2}
\end{figure}  

Figure \ref{fig:usecaseCrimeMap2} describes the design of following use cases:
\textit{see crime information, see statistics, show map} and \textit{share
information}. To share information of a crime, it is necessary to access the
Twitter micro-blogging service to proceed with the authentication and posting.
The service requires the user id and password, however the
application must ensure the User privacy information while performing
authentication. To see statistics of crimes, the application should process a
larger volume of data to generate statistical results. Thus, it is required
provide resources to ensure the data processing performance and how present it
to the User. The restriction on map presentation is over response time and
accessibility to postal services and Google maps. The response time limit 
is 5 seconds. If the map is not processed, only the information of the crime are
presented. Figures \ref{fig:usecaseCrimeMap1} and \ref{fig:usecaseCrimeMap2}
also show properties information details used in the $pi$SOD-M environment and
the equivalence concept in the model.
 
\begin{figure}[ht!]   
\centering
\includegraphics[width=0.8\textwidth]{chapters/validation/figs/crimesMap}
\caption{Crimes' Map Services.}
\label{fig:servicesCrimeMap}
\end{figure}
 
After the identification the various functions that are required by the system
to perform the business services, the $\pi$-ServiceProcess model is used to
represent the workflow necessary to perform a service in the system.
 
 
\subsubsection{$\pi$-ServiceProcess Model}
\label{sec:serviceprocess_crimesMap} 

After identify each function that is required by the
system to perform the services execution, the $\pi$-ServiceProcess model is
used to represent the workflow necessary to perform the system service.

The service processes execution is described in two
steps. Figures \ref{fig:serviceProcessCrimeMap} and \ref{fig:serviceProcessCrimeMap2} show the
flow of functions execution described in the $\pi$-useCase models shown
in Figures \ref{fig:usecaseCrimeMap1} and \ref{fig:usecaseCrimeMap2}.

Each diagram can represent different business services. Thus, it makes easier
to represent the performance of services. It is also possible to describe the
process in a large workflow, but for applications running multiple
services, it is better to have smaller processes to better represent the
service execution. Thus we present the services business through the different
processes as presented in Figures \ref{fig:usecaseCrimeMap1} and
\ref{fig:usecaseCrimeMap2}.

\begin{figure}[ht!]   
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/model_piServiceProcess}
\caption{\textit{see crime information} $\pi$-ServiceProcess Detail.}
\label{fig:serviceProcessCrimeMap}
\end{figure}  

\begin{figure}[ht!]    
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/toolServiceProcess_crime1}
\caption{\textit{see crime information}
$\pi$-ServiceComposition Environment Detail.}
\label{fig:toolserviceCompositionCrimeMap}
\end{figure} 

Each constraint is transformed into assertion, for example, to verify the
assertions of address format,  crime types and time are restrictions over 
the action \textit{search crime}, being one pre-condition and two
post-conditions. Thus, these restrictions form the contract on the \textit{search
crime} function. The same goes for viewing maps, if the answer to the request
takes longer than 5 seconds (5000 milliseconds), the map display is suspended and only 
the information is presented. Each assertion in this $\pi$-ServiceProcess model
stems from the $\pi$-UseCase model constraints. These restrictions are shown
in Figure \ref{fig:serviceProcessCrimeMap}. Figure
\ref{fig:toolserviceCompositionCrimeMap} presents the equivalent model
generated by the methodology transformation in the $\pi$SOD-M environment for
the process detailed in Figure \ref{fig:serviceProcessCrimeMap}. Each node
defines the process element and its properties.

In Figure \ref{fig:toolserviceCompositionCrimeMap}, \textit{i\_node} corresponds
to the initial process node. Each {\sc Action} are grouped into  {\sc Service
Activities}, such as \textit{choose crimes` property} action that is part of
the \textit{search crime} service activity. A {\sc Control Flow} is a edge that
links two nodes, for example \textit{cf1} connect the initial node
\textit{i\_node} (source) with the \textit{choose crimes' property} action
(target). Figure \ref{fig:toolserviceCompositionCrimeMap} also presents the
assertions described in Figure \ref{fig:serviceProcessCrimeMap} grouped into 
{\sc Contracts}. The contracts are: \textit{searchCrimeContract} and
\textit{seeCrimeInformationContract}. These contracts are related with the
actions \textit{search crime} and \textit{see crimes` information}.

\begin{figure}[ht!]   
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/model_piServiceProcess2}
\caption{\textit{see crime statistic and share information} $\pi$-ServiceProcess
Detail.}
\label{fig:serviceProcessCrimeMap2}
\end{figure}   


Figure \ref{fig:serviceProcessCrimeMap2} presents the assertions over the
 \textit{see statistics} and \textit{share information} actions. Both has 2 
pre-conditions. To \textit{share information} on Twitter is necessary verify the
format of crime information (140 characters) and the Twitter id and password, for
authentication. Regarding the \textit{see statistics} action, there is a
business restriction over data volume, and a value restriction over the crime
information format. Thus, the presentation of the crimes statistics must is done
after the contract verification. Figure
\ref{fig:toolserviceProcessCrimeMap2} presents the equivalent model
generated by the methodology transformation in the $\pi$SOD-M environment for
the process detailed in Figure \ref{fig:serviceProcessCrimeMap2}. Each node
defines the process element and its properties. Figure
\ref{fig:toolserviceProcessCrimeMap2} also presents the assertions grouped
into three contracts that are related with its specific actions. The contracts
are: \textit{seeStatisticsContract}, \textit{seeCrimeInformationContract} and
\textit{shareInformationContract}. The contract are related with the action
\textit{see statistics}, \textit{see crime`s information} and \textit{share
information}, respectively. 

\begin{figure}[ht!]    
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/toolServiceProcess_crime2}
\caption{\textit{see crime statistic and share information}
$\pi$-ServiceComposition Environment Detail.}
\label{fig:toolserviceProcessCrimeMap2}
\end{figure} 


These models provide an overview of the business processes from the requirements
described in the $\pi$-UseCase model. These models also provide a more detailed
view of how is the execution of business processes and how is the possible
interaction with external services. The description of this interaction is the result of
refinement of these models ($\pi$-ServiceProcess models) through the
$\pi$-ServiceComposition model.

\subsubsection{$\pi$-ServiceComposition Model}
\label{sec:servicecomposition_crimesMap} 

Figures \ref{fig:serviceCompositionCrimeMap} and
\ref{fig:serviceCompositionCrimeMap2} show the $\pi$-ServiceComposition models,
which represent the processes of service composition of each
business service and additional indication of which members of the business that
performed the action. For actions, they are derived from service activities,
identifying the set of actions that are necessary for the completion of each service.

The main partition express the \textit{Application} execution (\textit{External
false}) that represents the general process. Actions have the equivalent
service relation, which realize the external service, such as \textit{Police}, \textit{Google Maps} or
\textit{Twitter} services. They are expressed by a {\sc Business Collaborator}.
Both, Figure \ref{fig:serviceCompositionCrimeMap} and
\ref{fig:serviceCompositionCrimeMap2} present two external {\sc Business
Collaborators} describing the application services that are invoked. These
$\pi$-ServiceComposition models refine the $\pi$-ServiceProcess models, matching
action with real service functions that may be executed by the system
application. 

\begin{figure}[ht!]   
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/model_piServiceComposition}
\caption{\textit{see crime information}
$\pi$-ServiceComposition Detail.}
\label{fig:serviceCompositionCrimeMap} 
\end{figure} 


\begin{figure}[ht!]    
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/toolServiceCOmposition_crime1}
\caption{\textit{see crime information}
$\pi$-ServiceComposition Environment Detail.}
\label{fig:toolserviceCompositionCrimeMap}
\end{figure}  

For each $\pi$-ServiceComposition model, the contracts described in the
$\pi$-ServiceProcess model are grouped in policies. Figure
\ref{fig:serviceCompositionCrimeMap} describes the \textit{performancePolicy}
and \textit{reliabilityPolicy} policies, both associated with a service activity
and its actions. It is important to highlight that all policies are applied to the
entire actions associated with a service activity, for example, the
\textit{performancePolicy} verify the request time for presenting the Google
maps. If the time exceed 5000 milliseconds, the maps is ignored and only the
crime information is presented. However the \textit{reliabilityPolicy} is
associated with crime data verification. There are three rules over crime
address format, types of crime and the period it happens. The crime presentation
may obey the pre- and post-condition described in this policy. Figure
\ref{fig:toolserviceCompositionCrimeMap} presents the $\pi$SOD-M tool
description for the model described in Figure
\ref{fig:serviceCompositionCrimeMap}.

\begin{figure}[ht!]   
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/model_piServiceComposition2}
\caption{\textit{see crime statistic and share information}
$\pi$-ServiceComposition Detail.}
\label{fig:serviceCompositionCrimeMap2}
\end{figure}    

\begin{figure}[ht!]    
\centering
\includegraphics[width=0.99\textwidth]{chapters/validation/figs/toolServiceCOmposition_crime2}
\caption{\textit{see crime statistic and share information}
$\pi$-ServiceComposition Environment Detail.}
\label{fig:toolserviceCompositionCrimeMap2}
\end{figure}   

Figure \ref{fig:serviceCompositionCrimeMap2} refines the $\pi$-ServiceProcess
model described in Figure \ref{fig:serviceProcessCrimeMap2} and Figure
\ref{fig:toolserviceCompositionCrimeMap2} presents the $\pi$SOD-M tool
description for the model described in Figure
\ref{fig:serviceCompositionCrimeMap2}. This model detail the policies for the
\textit{see crime statistic} and \textit{share information} services. The
policies are \textit{statisticPolicy} and \textit{authenticationPolicy},
respectively. 

These models provide an overview of the external services and its composition
from the actions described in the $\pi$-ServiceProcess model. These models also
provide a more detailed view of the system restrictions, applying policies
over external services. This model refines the $\pi$-ServiceProcess models
detailing the Business Collaborators that are expressed as external services,
and grouping contract into policies. 

% From these composition models, next
% step is generate the specification system code in $\pi$-PEWS.

% \subsubsection{$\pi$-PEWS Model}
% \label{sec:pews_crimesMap}  


\subsection{To Publish Music}
\label{sec:toPublishMusic_inpractice}

 
 The second case study was presented as scenario for the description of the
 thesis' concepts. An organization wants to provide the services' based
 application that monitors the music a person is listening during some periods of time and sends the song title to this person's Twitter or Facebook accounts. Thus, this social
network user will have her status synchronized in Twitter or Facebook. The
scenario begins by get through the music service Spotify for fetching the user's
musical status. The social network services are then contacted for modify the
user's status with the music information. The user can also download a specific
music, he can proceed with the download process, which includes the payment
process.

The user can also download a music, but for this, the User may proceed with the
 payment via PayPal or credit card. All services are available via Spotify and
 this application needs to interact with Spotify users, so they can listen
 music, publish them on Facebook and Twitter, or buy it online. The scenario
 to monitor and publish songs have the following actors: \textit{(i) User, (ii)
 Spotify service, (iii) Facebook service, (iv) Twitter service} and \textit{(v)
 Bank service}.

The application requirements are: \textit{Search music; Choose music; Download
 music; Listen Music; Buy music} and \textit{Publish music}. 

 \subsubsection{$\pi$-UseCase Model}
\label{sec:usecase_topublishMusic}

  
Figure \ref{fig:publishMusic_usecase} shows the use case model for the
\textit{To Publish Music} application. The $\pi$-UseCase model
describes the system functions and constraints. Figures \ref{fig:toolpublishMusic_usecase} and
\ref{fig:toolpublishMusic_usecase2} present the model and configuration
properties for the described example made using the $\pi$SOD-M environment.


\begin{figure}[ht!]    
\centering
\includegraphics[width=.99\textwidth]{chapters/methodology/figs/piusecase/application/packages2.pdf}
\caption{\textit{To Publish Music} $\pi$-UseCase.}
\label{fig:publishMusic_usecase}
\end{figure} 

The application describe three restrictions on the use cases described in the
model, two on the \textit{buy music} use case and a restriction on the
\textit{pay} use case. This restrictions are value and business constraints.
\textit{buy music} restrictions are related to secure connection and the User
already has an account in the music network.

\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/implementation/figs/create_model-UseCase.pdf}
\caption{\textit{To Publish Music} $\pi$-UseCase Environment Detail}
\label{fig:toolpublishMusic_usecase}
\end{figure}

Figures \ref{fig:toolpublishMusic_usecase} and
\ref{fig:toolpublishMusic_usecase2} present the update music model and show how
the properties are defined in the $\pi$SOD-M environment. This example describe
the properties over the \textit{update music} use case and the restriction over
the authentication process. To update a music in a social network, the User must
process with the privacy authentication.

\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/implementation/figs/model-UseCase.pdf}
\caption{\textit{To Publish Music}$\pi$-UseCase Environment Detail 2.}
\label{fig:toolpublishMusic_usecase2}
\end{figure}

The modeling of the application properties using the environment $\pi$SOD-M
are the same presented in the $\pi$UseCase model, as described in Figure
\ref{fig:toolpublishMusic_usecase2}. For example, the authentication restriction
 details the type of constraint (\textit{VALUE}), a \textit{description},
 \textit{name} and a \textit{non-functional attribute}
 (\textit{authentication}). These properties are described in all constraints. 

Figure \ref{fig:servicesToPublishMusic} shows the service components that must
interact with the \textit{application}. As the application use third services,
this figure presents de interaction between them. There are four services that
are invoked to produce results for the \textit{Publish Music} application.

\begin{figure}[ht!]   
\centering
\includegraphics[width=0.8\textwidth]{chapters/validation/figs/toPublishMusic}
\caption{To Publish Music Services.}
\label{fig:servicesToPublishMusic}
\end{figure}  


 \subsubsection{$\pi$-ServiceProcess Model}
\label{sec:serviceProcess_topublishMusic}


  The contract based process of activities
execution is shown in Figure
\ref{fig:publishmusic_piserviceProcessToolModelProperties}. Thus, it is
necessary to represent each {\sc Constraint} modelled in a more representative {\sc Contract} based service activity diagram. Each constraint described in the
previous model is transformed into contract in the $\pi$-ServiceProcess model. 

\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/implementation/figs/model-ServiceProcess.pdf}
\caption{\textit{To Publish Music} $\pi$-ServiceProcess.}
\label{fig:publishmusic_piserviceProcessToolModelProperties}
\end{figure} 

\textit{Buy music}
and \textit{publish music} services (update Twitter and Facebook) has pre- and
post-conditions assertions that are composed into a contract for each service,
they are: (i) verify if the User data are correct; (ii) if the User is already
logged in Spotify; (iii) if bank details are correct and; (iv) if there is
enough money to make the payment. As post-condition, it ensures the complete
transaction and verify if a notification were sent to the user and Spotify, about the payment authorization. To \textit{update} services, depending
of each service, there may be different restrictions. 

 The Facebook service requires that the user is already logged on
 Spotify and these data are the same as Facebook. As post-condition, it ensures
 that the Facebook service send a notification of success. The Twitter service
  requires pre-conditions over the message length and user privacy data, while
  to update the Facebook is a necessary precondition and a confirmation notice as post-condition. As a precondition for ``\textit{twitter
update}'' it is necessary that \textit{(i)} the music format is correct and 
(\textit{ii})  the twitter login and password is correct for the update.   

The development of the $\pi$-ServiceProcess refine
the case study constraints into contracts for the services described
in Figure \ref{fig:servicesToPublishMusic}.

 \subsubsection{$\pi$-ServiceComposition Model}
\label{sec:serviceComposition_topublishMusic}

 There are four external {\sc Business
Collaborators}, they are: \textit{Bank, Spotify, Twitter} and \textit{Facebook}. 
Figure \ref{fig:topublishMusic_piserviceCompositionToolModel} shows the
application services that consists of a set of functions: \textit{search music,
select music, buy music, download music, listen music} and \textit{publish
music}. The \textit{publish music}  action calls
of two service collaborators (Facebook and Twitter), and the \textit{buy
music} action calls two functions in the Bank service collaborators.

\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/implementation/figs/create-model-Serviceconposition.pdf}
\caption{\textit{To Publish Music} $\pi$-ServiceComposition Model.}
\label{fig:topublishMusic_piserviceCompositionToolModel}
\end{figure}


The \textit{To Publish Music} $\pi$-ServiceComposition model defines three
policies, they are: \textit{trasactionPolicy, httpAuthPolicy} and
\textit{authPolicy}. The \textit{trasactionPolicy} policy verify the Bank data
restrictions over the payment and confirmation process. The
\textit{httpAuthPolicy} policy specifies rules over the Facebook function for
authentication and notification process. These rules are executed during the
publish massage function request. The \textit{authPolicy} policy implements the
open authentication protocol over the Twitter service. 


From the \textit{To Publish Music} rules and policies it is possible to model
and associate non-functional properties to services' compositions,
\textit{e.g.} the integration of information retrieved from different
social network services, automatic generation of an integrated view of the
operations executed in different social networks or for providing security in
the communication channel when the payment service is called.

%  \subsubsection{$\pi$-PEWS Model}
% \label{sec:pews_topublishMusic}


% \begin{figure}[ht!]
% \centering
% \includegraphics[width=.90\textwidth]{chapters/implementation/figs/create_model-PEWSProperties.pdf}
% \caption{$\pi$-PEWS Model Properties in $\pi$SOD-M Eclipse Plugin.} 
% \label{fig:piPEWSToolModelProperties}
% \end{figure}


% \section{Results}
% \label{sec:results} 

\section{Conclusions}
\label{sec:conclusion_validation}

This chapter presented the $\pi$SOD-M methodology validation. We
described, modeled and implemented two case studies to verify the
methodology concepts, model properties and process development. The
laboratory case studies helped setting the proposed approach, favoring
consistency of concepts and its application.
 
Despite being necessary a real case studies validation, not only
laboratory studies, the methodology execution and its concepts helped
the development of applications that use service compositions, mainly in
the identification and refinement of quality requirements. The use of $\pi$SOD-M
and its environment in real development cases can help identify the
non-functional requirements and improve the system modeling and specification
process.
 
The transformations between models help the semi-automatic model-driven develop 
applications. Using this approach makes the details of each system be described,
in particular in the use cases presented, the non-functional requirements could
be refined, so that policies of each application were specified according to
the system requirements.  

The generation of the system specification code from the service composition
model presents as a advantage, because the designer and developer can focus on
the description and detail of function and non-functional requirements, and not
on the implementation code. The generated code is not a final version of the
system specification, but the main and important description of service
interaction and its namespace. However, this specification can be already
verified and executed after the model transformation.

As the process is iterative and incremental, after generation of each model is
possible to make adjustments to the generated model. For example, after the
$\pi$-UseCase model design and the generation of $\pi$-ServiceProcess 
model, the designer can make adjustments and improve the model so that it
becomes more expressive. Thus, $\pi$SOD-M is characterized as a semi-automatic
development methodology. In the validation development, this incremental
activities increased helped to identify na\"{\i}ve  modeling requirements, favoring
that initial errors were immediately corrected.

In general, the development $\pi$SOD-M favored and improved modeling
services from more abstract levels development and to identify non-functional
requirements related with each of these services.
